home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 011 / tsr.arc / TSR.DOC < prev   
Encoding:
Text File  |  1986-05-22  |  8.6 KB  |  205 lines
  1. **********************************************************************
  2. *                                                                    *
  3. *    The TSR package is a group of programs useful in managing       *
  4. *    DOS memory, and in particular managing memory-resident          *
  5. *    utilities. TSR stands for "Terminate and Stay Resident".        *
  6. *                                                                    *
  7. **********************************************************************
  8.  
  9. MARK.COM and RELEASE.COM are used to remove memory-resident
  10. programs from memory, without the usual problems of creating
  11. holes or leaving interrupts dangling. The two programs are used
  12. simply as follows:
  13.  
  14. 1) Run the program MARK.COM before installing any memory-
  15.    resident program that you may wish to deinstall later.
  16.    This marks the current position in memory and stores the
  17.    DOS interrupt vector table (all interrupts from 0 to FFH).
  18.  
  19. 2) Install whatever TSRs that you want to use, in the normal
  20.    way that you install them.
  21.  
  22. 3) When you want to deinstall all TSRs above the last MARK,
  23.    run the program RELEASE.COM. This will release all of the
  24.    memory above (and including) the last MARK, and restore
  25.    all interrupt vectors taken over by the memory resident
  26.    programs.
  27.  
  28. MARK and RELEASE can be "stacked" as many times as desired.
  29. RELEASE releases the memory above the last MARK call.
  30. MARK uses about 1600 bytes of memory each time it is called.
  31. This 1600 byte region is also released when a RELEASE is done.
  32. MARK memory usage is dominated by the copies of the DOS
  33. interrupt vector table (interrupts 0..FFH) and the copy
  34. of the EMS page map (blocks 0..31 only) which MARK keeps
  35. when it goes resident.
  36.  
  37. MARK and RELEASE can optionally be called with a single command
  38. line parameter:
  39.  
  40.   MARK MarkName
  41.   RELEASE MarkName
  42.  
  43. In this way a particular mark is given a name. Calling RELEASE
  44. with the same name will release all memory above and including
  45. the mark of that name, also releasing any intermediate marks in
  46. the process. If no mark of the proper name is found, RELEASE will
  47. halt with a warning. A RELEASE call with no MarkName specified
  48. will release the last MARK, whether or not that MARK was named.
  49.  
  50. The MarkName can be any text string up to 126 characters in length.
  51. It may not contain embedded blanks or tabs. Case (upper or lower)
  52. is not important when matching MarkNames.
  53.  
  54. MarkName supports an additional feature. If the MarkName begins
  55. with ! (exclamation point), then the mark is called a "protected
  56. mark". That mark can be released *only* by an exact match to its
  57. name (including the exclamation point). A protected mark will NOT
  58. be released with an "unnamed" RELEASE. Any named or unnamed RELEASE
  59. which encounters a protected mark that it does not match exactly,
  60. will stop without releasing any blocks.
  61.  
  62. As of version 1.4, MARK and RELEASE also control Expanded memory
  63. (Lotus/Intel/Microsoft EMS). They have been tested with READY!
  64. and with the TurboPower Software expanded memory disk cache, as
  65. well as with the device drivers used by the STB Expanded Memory
  66. Card.
  67.  
  68. WARNING: if a resident application allocates expanded memory
  69. at some time >after< going resident and after the last MARK made,
  70. that expanded memory will be released by a call to RELEASE.
  71. The current expanded memory manager (EMM) does not give us enough
  72. information to avoid this possibility. Fortunately, there are
  73. no known memory resident programs which perform this dynamic
  74. allocation of expanded memory. We hope that the EMM will be
  75. upgraded before such applications are designed.
  76.  
  77. As of version 1.6, RELEASE takes special precautions to allow
  78. it to release extra invocations of the DOS command processor.
  79. In the simplest form, an extra command processor is obtained
  80. by typing COMMAND at the DOS level. Many multitasking or
  81. switching utilities also utilize this feature of DOS, and these
  82. utilities can now be managed via MARK and RELEASE.
  83.  
  84. Due to the way DOS handles batch files, there are certain limitations
  85. on using RELEASE within batch. It is *not* possible to perform the
  86. following sequence of events successfully:
  87.  
  88. First, from the command line:
  89.  
  90.   MARK
  91.   SK      {or any other resident program or programs}
  92.  
  93. Then, within a batch file:
  94.  
  95.   RELEASE {get rid of SK and MARK}
  96.   LOTUS   {run Lotus using the additional memory}
  97.   MARK    {put SK back in place}
  98.   SK
  99.  
  100. DOS allocates a small memory block prior to running any
  101. batch file. It does not allow that block to be deallocated
  102. from within the batch file without various errors occurring.
  103. As a result, in this case the MARK and SK memory blocks are
  104. effectively trapped until the batch file is completed, after
  105. which the memory will be reusable. Indeed, if you run the
  106. batch file presented above, you will get MARK and SK
  107. installed above a big hole in memory left by the previous
  108. images of MARK and SK.
  109.  
  110. RELEASE now guards against this possibility. If it senses
  111. that you are attempting to release memory trapped by a
  112. "batch control block", it writes a warning message to that
  113. effect. It still releases the memory, but when it exits
  114. it passes back a return code of 1 rather than the usual
  115. value of 0.
  116.  
  117. It *is* possible to get the desired effect in either of
  118. at least two ways. First, you could make two batch files
  119. and call them one after the other:
  120.  
  121. Batch file #1:
  122.   RELEASE
  123.  
  124. Batch file #2:
  125.   LOTUS
  126.   MARK
  127.   SK
  128.  
  129. In this case, running RELEASE in batch file #1 has the
  130. same effect as running RELEASE from the command line.
  131. Directly calling the second batch file from the first
  132. doesn't always seem to work either. The only sure bet
  133. appears to be the use of a keypoker like KEY-FAKE or
  134. PCED's KEYIN.
  135.  
  136. A better way to make these things happen is to use the
  137. public domain program CED, or its commercial upgrade
  138. PCED. These programs allow you to define "synonyms" for
  139. groups of commands. The commands execute one after the
  140. other just like a batch file. However, the synonyms do
  141. not create an extra batch control memory block which
  142. causes the problems just described.
  143.  
  144. Thus you could make two CED synonyms as follows.
  145. (We assume that the CED "chain character" is ^).
  146.  
  147. SYN LOADSK mark !sk^sk
  148.   {make a protected sidekick marker and load sidekick}
  149.  
  150. SYN RUNLOT release !sk^lotus^mark !sk^sk
  151.   {release sidekick if it's there, run lotus, then reload sidekick}
  152.  
  153.  
  154. **********************************************************************
  155.  
  156. MAPMEM.COM is used to display the current DOS memory map. It shows
  157. the resident programs, how much memory they use, and what interrupt
  158. vectors each currently owns. MAPMEM also shows information about
  159. expanded memory when such a driver is installed. MAPMEM writes to
  160. the standard output - thus the output can be printed or stored
  161. to a file.
  162.  
  163. Calling MAPMEM with a "V" command line parameter (i.e., MAPMEM /V)
  164. will show additional information about each memory block. MAPMEM
  165. will also accept V or -V as the command line switch for the
  166. "verbose" option. The "Files" column shows the number of file
  167. handles that each resident block has kept open. Each block of
  168. memory reported by DOS is listed individually in verbose mode.
  169. This is useful in debugging problems, either with the TSR package
  170. itself, or perhaps with the resident programs that you are using.
  171.  
  172. RAMFREE.COM supplies a quick way to determine the amount of free RAM
  173. (without going through CHKDSK).
  174.  
  175. EATMEM.COM is useful for development work where you want to test
  176. software in an environment with a desired amount of available memory.
  177. Note that the memory used by EATMEM can be freed up by using MARK
  178. and RELEASE. EATMEM is called with a single command line parameter,
  179. specifying the (decimal) number of KILOBYTES to eat up.
  180.  
  181. **********************************************************************
  182.  
  183. All of these programs should work on any system running PCDOS or
  184. MSDOS 2.0 or later. They were developed on a Compaq Deskpro
  185. 286 running Compaq DOS 3.0. Source code is available in the file
  186. TSRSRC.ARC. The programs are written in assembly language (CHASM)
  187. and Turbo Pascal. TSRSRC requires that you have Turbo Pascal
  188. version 3.
  189.  
  190.      Written by Kim Kokkonen,
  191.      TurboPower Software
  192.      478 W. Hamilton Ave. #196
  193.      Campbell, CA 95008
  194.      Telephone: 408-378-3672 (M-F 9AM-5PM only)
  195.      Compuserve: 72457,2131
  196.  
  197.      Version 1.9 - 5/22/86.
  198.  
  199. The programs have been released to the public domain for personal,
  200. non-commercial use only. You may use them yourself, give them to
  201. your friends or co-workers, or distribute them for a cost-based
  202. fee as part of a user's group or bulletin board service. If you
  203. wish to distribute these programs as part of a commercial package,
  204. please contact us for a license agreement.
  205.